昨天驗收 CareCall AI 時，我確認目前只有「今日關懷總覽」是實際畫面，其他功能仍待完成。今天我沒有急著增加頁面，而是先整理四位虛構 Demo 與四種工作狀態，因為如果資料和判斷方式不一致，後面做出的每個畫面都可能需要重寫。

原本三種情境看起來已經很完整：林阿春完成服藥與量測，沒有不適或協助需求；王秀蘭沒有回答，需要再次提醒；陳明德有回答，但尚未量測，還提到站起來有點頭暈，因此需要人工確認。這三位分別代表「已完成」、「待提醒」和「待人工確認」。

但是三個案例仍缺少一種重要狀況：如果個案已經明確說自己不舒服，而且主動提出協助需求，系統不應只是把他放進一般的待確認清單。第四位李春美就是為了補上這個情境。她的狀態是「優先處理」，原因不是 AI 判斷她病情比較嚴重，而是她已經清楚表達需要協助，工作流程應優先交給照護人員。

今天我也把四種狀態的進入條件、原因、資料缺漏與下一步逐一寫清楚。「已完成」需要取得回答、必要資料完整，而且沒有不適或求助；「待提醒」表示沒有取得回答，不能把沉默當成平安；「待人工確認」代表已有回答，但資訊不完整或語意需要人員釐清；「優先處理」則是在出現明確不適或求助時，優先讓人員接手。

另一項重要改變，是把原本直接寫在畫面程式裡的 Demo 資料移出來。我建立共用的 TypeScript 型別，以及唯一的 Demo 資料與狀態規則來源。首頁看起來幾乎沒有改變，但未來的個案詳細、關懷流程和人工處理中心都可以使用同一份資料，不必每做一頁就複製一次姓名、狀態和判定原因。

這一步也讓我更清楚理解，CareCall AI 顯示的是「工作流程狀態」，不是醫療診斷或病情嚴重程度。系統的任務是保存回答、指出缺漏、安排提醒與人工接手，而不是替照護人員作醫療判斷。

今日反思

增加第四個案例不是為了讓展示看起來更豐富，而是補上原本無法清楚表達的求助情境。當每個案例都有明確目的，Demo 才能真正幫助我們檢查產品流程。